محدودیت نرخ در پایتون: سطل نشانه در مقابل پنجره لغزان - راهنمای جامع

در دنیای متصل امروزی، APIهای قوی برای موفقیت برنامه‌ها حیاتی هستند. با این حال، دسترسی کنترل‌نشده به API می‌تواند منجر به بار بیش از حد سرور، افت کیفیت سرویس و حتی حملات منع سرویس (DoS) شود. محدودیت نرخ (Rate limiting) یک تکنیک حیاتی برای محافظت از APIهای شما با محدود کردن تعداد درخواست‌هایی است که یک کاربر یا سرویس می‌تواند در یک بازه زمانی مشخص ارسال کند. این مقاله به بررسی دو الگوریتم محبوب محدودیت نرخ در پایتون می‌پردازد: سطل نشانه (Token Bucket) و پنجره لغزان (Sliding Window)، و مقایسه‌ای جامع همراه با مثال‌های عملی پیاده‌سازی ارائه می‌دهد.

چرا محدودیت نرخ اهمیت دارد

محدودیت نرخ مزایای بی‌شماری دارد، از جمله:

• جلوگیری از سوءاستفاده: کاربران مخرب یا ربات‌ها را از تحت فشار قرار دادن سرورهای شما با درخواست‌های بیش از حد محدود می‌کند.
• تضمین استفاده منصفانه: منابع را به طور مساوی بین کاربران توزیع می‌کند و از انحصارطلبی یک کاربر جلوگیری می‌کند.
• محافظت از زیرساخت: از سرورها و پایگاه‌های داده شما در برابر بار بیش از حد و از کار افتادن محافظت می‌کند.
• کنترل هزینه‌ها: از افزایش ناگهانی مصرف منابع جلوگیری کرده و منجر به صرفه‌جویی در هزینه‌ها می‌شود.
• بهبود عملکرد: با جلوگیری از اتمام منابع و تضمین زمان پاسخ‌دهی ثابت، عملکرد پایدار را حفظ می‌کند.

درک الگوریتم‌های محدودیت نرخ

چندین الگوریتم محدودیت نرخ وجود دارد که هر کدام نقاط قوت و ضعف خود را دارند. ما بر روی دو الگوریتم پرکاربرد تمرکز خواهیم کرد: سطل نشانه و پنجره لغزان.

۱. الگوریتم سطل نشانه (Token Bucket)

الگوریتم سطل نشانه یک تکنیک ساده و پرکاربرد برای محدودیت نرخ است. این الگوریتم با نگهداری یک «سطل» که حاوی نشانه‌ها (token) است، کار می‌کند. هر نشانه، مجوز ارسال یک درخواست را نشان می‌دهد. سطل دارای ظرفیت حداکثری است و نشانه‌ها با نرخ ثابتی به آن اضافه می‌شوند.

هنگامی که یک درخواست می‌رسد، محدودکننده نرخ بررسی می‌کند که آیا به تعداد کافی نشانه در سطل وجود دارد یا خیر. اگر وجود داشته باشد، به درخواست اجازه داده می‌شود و تعداد متناظر نشانه‌ها از سطل حذف می‌شود. اگر سطل خالی باشد، درخواست رد شده یا تا زمانی که نشانه‌های کافی در دسترس قرار گیرند، به تعویق می‌افتد.

پیاده‌سازی سطل نشانه در پایتون

در اینجا یک پیاده‌سازی ساده پایتون از الگوریتم سطل نشانه با استفاده از ماژول threading برای مدیریت همزمانی ارائه شده است:

import time
import threading

class TokenBucket:
    def __init__(self, capacity, fill_rate):
        self.capacity = float(capacity)
        self._tokens = float(capacity)
        self.fill_rate = float(fill_rate)
        self.last_refill = time.monotonic()
        self.lock = threading.Lock()

    def _refill(self):
        now = time.monotonic()
        delta = now - self.last_refill
        tokens_to_add = delta * self.fill_rate
        self._tokens = min(self.capacity, self._tokens + tokens_to_add)
        self.last_refill = now

    def consume(self, tokens):
        with self.lock:
            self._refill()
            if self._tokens >= tokens:
                self._tokens -= tokens
                return True
            return False

# Example Usage
bucket = TokenBucket(capacity=10, fill_rate=2)  # 10 tokens, refill at 2 tokens per second

for i in range(15):
    if bucket.consume(1):
        print(f"Request {i+1}: Allowed")
    else:
        print(f"Request {i+1}: Rate Limited")
    time.sleep(0.2)

توضیحات:

• TokenBucket(capacity, fill_rate): سطل را با یک ظرفیت حداکثر و یک نرخ پر شدن (تعداد نشانه‌ها در ثانیه) مقداردهی اولیه می‌کند.
• _refill(): سطل را بر اساس زمان سپری شده از آخرین پر شدن، با نشانه‌ها پر می‌کند.
• consume(tokens): تلاش می‌کند تا تعداد مشخصی از نشانه‌ها را مصرف کند. در صورت موفقیت (درخواست مجاز است)، True برمی‌گرداند، در غیر این صورت (درخواست محدود شده است)، False برمی‌گرداند.
• قفل نخ (Threading Lock): از یک قفل نخ (self.lock) برای تضمین ایمنی در محیط‌های همزمان (thread-safe) استفاده می‌کند.

مزایای سطل نشانه

• پیاده‌سازی ساده: درک و پیاده‌سازی آن نسبتاً آسان است.
• مدیریت ترافیک ناگهانی (Burst): می‌تواند ترافیک‌های ناگهانی و کوتاه‌مدت را تا زمانی که سطل نشانه‌های کافی داشته باشد، مدیریت کند.
• قابل تنظیم: ظرفیت و نرخ پر شدن را می‌توان به راحتی برای برآورده کردن نیازهای خاص تنظیم کرد.

معایب سطل نشانه

• دقت نه چندان کامل: ممکن است به دلیل مکانیسم پر شدن، کمی بیشتر از نرخ تنظیم‌شده به درخواست‌ها اجازه دهد.
• تنظیم پارامترها: برای دستیابی به رفتار مطلوب محدودیت نرخ، نیاز به انتخاب دقیق ظرفیت و نرخ پر شدن دارد.

۲. الگوریتم پنجره لغزان (Sliding Window)

الگوریتم پنجره لغزان یک تکنیک دقیق‌تر برای محدودیت نرخ است که زمان را به پنجره‌هایی با اندازه ثابت تقسیم می‌کند. این الگوریتم تعداد درخواست‌های ارسال شده در هر پنجره را ردیابی می‌کند. هنگامی که یک درخواست جدید می‌رسد، الگوریتم بررسی می‌کند که آیا تعداد درخواست‌ها در پنجره فعلی از حد مجاز فراتر رفته است یا خیر. اگر چنین باشد، درخواست رد شده یا به تعویق می‌افتد.

جنبه «لغزان» بودن از این واقعیت ناشی می‌شود که با رسیدن درخواست‌های جدید، پنجره در زمان به جلو حرکت می‌کند. هنگامی که پنجره فعلی به پایان می‌رسد، یک پنجره جدید شروع می‌شود و شمارنده بازنشانی می‌شود. دو نوع اصلی از الگوریتم پنجره لغزان وجود دارد: لاگ لغزان (Sliding Log) و شمارنده پنجره ثابت (Fixed Window Counter).

۲.۱. لاگ لغزان

الگوریتم لاگ لغزان یک لاگ زمان‌بندی شده از هر درخواست ارسال شده در یک پنجره زمانی مشخص را نگهداری می‌کند. هنگامی که یک درخواست جدید می‌رسد، تمام درخواست‌های موجود در لاگ که در بازه پنجره زمانی قرار دارند را جمع کرده و با حد نرخ مقایسه می‌کند. این روش دقیق است، اما می‌تواند از نظر حافظه و قدرت پردازش پرهزینه باشد.

۲.۲. شمارنده پنجره ثابت

الگوریتم شمارنده پنجره ثابت، زمان را به پنجره‌های ثابت تقسیم کرده و برای هر پنجره یک شمارنده نگه می‌دارد. هنگامی که یک درخواست جدید می‌رسد، الگوریتم شمارنده پنجره فعلی را افزایش می‌دهد. اگر شمارنده از حد مجاز فراتر رود، درخواست رد می‌شود. این روش ساده‌تر از لاگ لغزان است، اما می‌تواند به یک ترافیک ناگهانی در مرز دو پنجره اجازه دهد.

پیاده‌سازی پنجره لغزان در پایتون (شمارنده پنجره ثابت)

در اینجا یک پیاده‌سازی پایتون از الگوریتم پنجره لغزان با استفاده از رویکرد شمارنده پنجره ثابت ارائه شده است:

import time
import threading

class SlidingWindowCounter:
    def __init__(self, window_size, max_requests):
        self.window_size = window_size  # seconds
        self.max_requests = max_requests
        self.request_counts = {}
        self.lock = threading.Lock()

    def is_allowed(self, client_id):
        with self.lock:
            current_time = int(time.time())
            window_start = current_time - self.window_size

            # Clean up old requests
            self.request_counts = {ts: count for ts, count in self.request_counts.items() if ts > window_start}

            total_requests = sum(self.request_counts.values())

            if total_requests < self.max_requests:
                self.request_counts[current_time] = self.request_counts.get(current_time, 0) + 1
                return True
            else:
                return False


# Example Usage
window_size = 60  # 60 seconds
max_requests = 10  # 10 requests per minute
rate_limiter = SlidingWindowCounter(window_size, max_requests)

client_id = "user123"

for i in range(15):
    if rate_limiter.is_allowed(client_id):
        print(f"Request {i+1}: Allowed")
    else:
        print(f"Request {i+1}: Rate Limited")
    time.sleep(5)

توضیحات:

• SlidingWindowCounter(window_size, max_requests): اندازه پنجره (به ثانیه) و حداکثر تعداد درخواست‌های مجاز در پنجره را مقداردهی اولیه می‌کند.
• is_allowed(client_id): بررسی می‌کند که آیا مشتری مجاز به ارسال درخواست است یا خیر. این متد درخواست‌های قدیمی خارج از پنجره را پاک می‌کند، درخواست‌های باقی‌مانده را جمع می‌زند و در صورتی که حد مجاز رد نشده باشد، شمارنده پنجره فعلی را افزایش می‌دهد.
• self.request_counts: یک دیکشنری که مهرهای زمانی درخواست‌ها و تعداد آنها را ذخیره می‌کند و امکان تجمیع و پاکسازی درخواست‌های قدیمی‌تر را فراهم می‌کند.
• قفل نخ (Threading Lock): از یک قفل نخ (self.lock) برای تضمین ایمنی در محیط‌های همزمان استفاده می‌کند.

مزایای پنجره لغزان

• دقیق‌تر: محدودیت نرخ دقیق‌تری نسبت به سطل نشانه فراهم می‌کند، به ویژه در پیاده‌سازی لاگ لغزان.
• جلوگیری از ترافیک ناگهانی در مرزها: احتمال بروز ترافیک ناگهانی در مرز دو پنجره زمانی را کاهش می‌دهد (در لاگ لغزان مؤثرتر است).

معایب پنجره لغزان

• پیچیده‌تر: پیاده‌سازی و درک آن در مقایسه با سطل نشانه پیچیده‌تر است.
• سربار بالاتر: می‌تواند سربار بالاتری داشته باشد، به ویژه در پیاده‌سازی لاگ لغزان، به دلیل نیاز به ذخیره و پردازش لاگ‌های درخواست.

سطل نشانه در مقابل پنجره لغزان: مقایسه‌ای دقیق

در اینجا جدولی برای خلاصه‌سازی تفاوت‌های کلیدی بین الگوریتم‌های سطل نشانه و پنجره لغزان آورده شده است:

ویژگی	سطل نشانه	پنجره لغزان
پیچیدگی	ساده‌تر	پیچیده‌تر
دقت	دقت کمتر	دقت بیشتر
مدیریت ترافیک ناگهانی	خوب	خوب (به‌ویژه لاگ لغزان)
سربار	پایین‌تر	بالاتر (به‌ویژه لاگ لغزان)
تلاش برای پیاده‌سازی	آسان‌تر	دشوارتر

انتخاب الگوریتم مناسب

انتخاب بین سطل نشانه و پنجره لغزان به نیازها و اولویت‌های خاص شما بستگی دارد. عوامل زیر را در نظر بگیرید:

• دقت: اگر به محدودیت نرخ با دقت بالا نیاز دارید، الگوریتم پنجره لغزان عموماً ترجیح داده می‌شود.
• پیچیدگی: اگر سادگی در اولویت است، الگوریتم سطل نشانه انتخاب خوبی است.
• عملکرد: اگر عملکرد حیاتی است، سربار الگوریتم پنجره لغزان، به ویژه پیاده‌سازی لاگ لغزان، را به دقت در نظر بگیرید.
• مدیریت ترافیک ناگهانی: هر دو الگوریتم می‌توانند ترافیک ناگهانی را مدیریت کنند، اما پنجره لغزان (لاگ لغزان) محدودیت نرخ سازگارتری در شرایط ترافیک ناگهانی فراهم می‌کند.
• مقیاس‌پذیری: برای سیستم‌های بسیار مقیاس‌پذیر، استفاده از تکنیک‌های محدودیت نرخ توزیع‌شده (که در ادامه بحث می‌شود) را در نظر بگیرید.

در بسیاری از موارد، الگوریتم سطل نشانه سطح کافی از محدودیت نرخ را با هزینه پیاده‌سازی نسبتاً پایینی فراهم می‌کند. با این حال، برای برنامه‌هایی که به محدودیت نرخ دقیق‌تری نیاز دارند و می‌توانند پیچیدگی افزایش‌یافته را تحمل کنند، الگوریتم پنجره لغزان گزینه بهتری است.

محدودیت نرخ توزیع‌شده

در سیستم‌های توزیع‌شده، که در آن چندین سرور درخواست‌ها را مدیریت می‌کنند، اغلب به یک مکانیزم متمرکز محدودیت نرخ نیاز است تا محدودیت نرخ سازگاری در تمام سرورها تضمین شود. چندین رویکرد برای محدودیت نرخ توزیع‌شده وجود دارد:

• ذخیره‌گاه داده متمرکز: از یک ذخیره‌گاه داده متمرکز مانند Redis یا Memcached برای ذخیره وضعیت محدودیت نرخ (مانند تعداد نشانه‌ها یا لاگ‌های درخواست) استفاده کنید. تمام سرورها برای اعمال محدودیت‌ها به این ذخیره‌گاه داده مشترک دسترسی پیدا کرده و آن را به‌روز می‌کنند.
• محدودیت نرخ توسط Load Balancer: Load Balancer خود را طوری پیکربندی کنید که بر اساس آدرس IP، شناسه کاربر یا معیارهای دیگر، محدودیت نرخ را انجام دهد. این رویکرد می‌تواند بار محدودیت نرخ را از روی سرورهای برنامه شما بردارد.
• سرویس اختصاصی محدودیت نرخ: یک سرویس اختصاصی برای محدودیت نرخ ایجاد کنید که تمام درخواست‌های مربوط به محدودیت نرخ را مدیریت کند. این سرویس می‌تواند به طور مستقل مقیاس‌بندی شده و برای عملکرد بهینه شود.
• محدودیت نرخ سمت کلاینت: اگرچه این یک دفاع اولیه نیست، اما کلاینت‌ها را از محدودیت‌های نرخ خود از طریق هدرهای HTTP (مانند X-RateLimit-Limit، X-RateLimit-Remaining، X-RateLimit-Reset) مطلع کنید. این کار می‌تواند کلاینت‌ها را تشویق کند تا خودشان ترافیک را کنترل کرده و درخواست‌های غیرضروری را کاهش دهند.

در اینجا مثالی از استفاده از Redis با الگوریتم سطل نشانه برای محدودیت نرخ توزیع‌شده آورده شده است:

import redis
import time

class RedisTokenBucket:
    def __init__(self, redis_client, bucket_key, capacity, fill_rate):
        self.redis_client = redis_client
        self.bucket_key = bucket_key
        self.capacity = capacity
        self.fill_rate = fill_rate

    def consume(self, tokens):
        now = time.time()
        capacity = self.capacity
        fill_rate = self.fill_rate

        # Lua script to atomically update the token bucket in Redis
        script = '''
        local bucket_key = KEYS[1]
        local capacity = tonumber(ARGV[1])
        local fill_rate = tonumber(ARGV[2])
        local tokens_to_consume = tonumber(ARGV[3])
        local now = tonumber(ARGV[4])

        local last_refill = redis.call('get', bucket_key .. ':last_refill')
        if not last_refill then
            last_refill = now
            redis.call('set', bucket_key .. ':last_refill', now)
        else
            last_refill = tonumber(last_refill)
        end

        local tokens = redis.call('get', bucket_key .. ':tokens')
        if not tokens then
            tokens = capacity
            redis.call('set', bucket_key .. ':tokens', capacity)
        else
            tokens = tonumber(tokens)
        end

        -- Refill the bucket
        local time_since_last_refill = now - last_refill
        local tokens_to_add = time_since_last_refill * fill_rate
        tokens = math.min(capacity, tokens + tokens_to_add)

        -- Consume tokens
        if tokens >= tokens_to_consume then
            tokens = tokens - tokens_to_consume
            redis.call('set', bucket_key .. ':tokens', tokens)
            redis.call('set', bucket_key .. ':last_refill', now)
            return 1  -- Success
        else
            return 0  -- Rate limited
        end
        '''

        # Execute the Lua script
        consume_script = self.redis_client.register_script(script)
        result = consume_script(keys=[self.bucket_key], args=[capacity, fill_rate, tokens, now])
        return result == 1


# Example Usage
redis_client = redis.StrictRedis(host='localhost', port=6379, db=0)
bucket = RedisTokenBucket(redis_client, bucket_key='my_api:user123', capacity=10, fill_rate=2)

for i in range(15):
    if bucket.consume(1):
        print(f"Request {i+1}: Allowed")
    else:
        print(f"Request {i+1}: Rate Limited")
    time.sleep(0.2)

ملاحظات مهم برای سیستم‌های توزیع‌شده:

• اتمی بودن (Atomicity): اطمینان حاصل کنید که عملیات مصرف نشانه یا شمارش درخواست‌ها اتمی هستند تا از شرایط رقابتی (race conditions) جلوگیری شود. اسکریپت‌های Lua در Redis عملیات اتمی را فراهم می‌کنند.
• تأخیر (Latency): تأخیر شبکه هنگام دسترسی به ذخیره‌گاه داده متمرکز را به حداقل برسانید.
• مقیاس‌پذیری (Scalability): یک ذخیره‌گاه داده انتخاب کنید که بتواند برای مدیریت بار مورد انتظار مقیاس‌پذیر باشد.
• سازگاری داده‌ها (Data Consistency): به مسائل بالقوه سازگاری داده‌ها در محیط‌های توزیع‌شده رسیدگی کنید.

بهترین شیوه‌ها برای محدودیت نرخ

در اینجا برخی از بهترین شیوه‌ها برای پیاده‌سازی محدودیت نرخ آورده شده است:

• شناسایی نیازمندی‌های محدودیت نرخ: محدودیت‌های نرخ مناسب را برای نقاط پایانی (endpoints) مختلف API و گروه‌های کاربری بر اساس الگوهای استفاده و مصرف منابع آنها تعیین کنید. ارائه دسترسی لایه‌بندی شده بر اساس سطح اشتراک را در نظر بگیرید.
• استفاده از کدهای وضعیت HTTP معنادار: برای نشان دادن محدودیت نرخ، کدهای وضعیت HTTP مناسب مانند 429 Too Many Requests را برگردانید.
• اضافه کردن هدرهای محدودیت نرخ: هدرهای محدودیت نرخ را در پاسخ‌های API خود بگنجانید تا کلاینت‌ها را از وضعیت فعلی محدودیت نرخ خود مطلع کنید (مثلاً X-RateLimit-Limit، X-RateLimit-Remaining، X-RateLimit-Reset).
• ارائه پیام‌های خطای واضح: هنگامی که کلاینت‌ها با محدودیت نرخ مواجه می‌شوند، پیام‌های خطای آموزنده‌ای ارائه دهید که دلیل آن را توضیح داده و نحوه حل مشکل را پیشنهاد کند. اطلاعات تماس برای پشتیبانی را ارائه دهید.
• پیاده‌سازی کاهش تدریجی کیفیت سرویس (Graceful Degradation): هنگامی که محدودیت نرخ اعمال می‌شود، به جای مسدود کردن کامل درخواست‌ها، ارائه یک سرویس با کیفیت کاهش‌یافته را در نظر بگیرید. به عنوان مثال، داده‌های کش شده یا عملکرد کاهش‌یافته را ارائه دهید.
• نظارت و تحلیل محدودیت نرخ: سیستم محدودیت نرخ خود را برای شناسایی مشکلات احتمالی و بهینه‌سازی عملکرد آن نظارت کنید. الگوهای استفاده را برای تنظیم محدودیت‌های نرخ در صورت نیاز تحلیل کنید.
• ایمن‌سازی محدودیت نرخ خود: با اعتبارسنجی درخواست‌ها و پیاده‌سازی اقدامات امنیتی مناسب، از دور زدن محدودیت‌های نرخ توسط کاربران جلوگیری کنید.
• مستندسازی محدودیت‌های نرخ: سیاست‌های محدودیت نرخ خود را به وضوح در مستندات API خود مستند کنید. کد نمونه‌ای ارائه دهید که به کلاینت‌ها نشان دهد چگونه با محدودیت‌های نرخ برخورد کنند.
• تست پیاده‌سازی خود: پیاده‌سازی محدودیت نرخ خود را تحت شرایط بار مختلف به طور کامل تست کنید تا از عملکرد صحیح آن اطمینان حاصل کنید.
• در نظر گرفتن تفاوت‌های منطقه‌ای: هنگام استقرار جهانی، تفاوت‌های منطقه‌ای در تأخیر شبکه و رفتار کاربران را در نظر بگیرید. ممکن است لازم باشد محدودیت‌های نرخ را بر اساس منطقه تنظیم کنید. به عنوان مثال، یک بازار مبتنی بر موبایل مانند هند ممکن است به محدودیت‌های نرخ متفاوتی در مقایسه با یک منطقه با پهنای باند بالا مانند کره جنوبی نیاز داشته باشد.

مثال‌های واقعی

• توییتر: توییتر به طور گسترده از محدودیت نرخ برای محافظت از API خود در برابر سوءاستفاده و تضمین استفاده منصفانه استفاده می‌کند. آنها مستندات دقیقی در مورد محدودیت‌های نرخ خود ارائه می‌دهند و از هدرهای HTTP برای اطلاع‌رسانی به توسعه‌دهندگان در مورد وضعیت محدودیت نرخ خود استفاده می‌کنند.
• گیت‌هاب: گیت‌هاب نیز از محدودیت نرخ برای جلوگیری از سوءاستفاده و حفظ پایداری API خود استفاده می‌کند. آنها از ترکیبی از محدودیت‌های نرخ مبتنی بر IP و مبتنی بر کاربر استفاده می‌کنند.
• استرایپ: استرایپ از محدودیت نرخ برای محافظت از API پردازش پرداخت خود در برابر فعالیت‌های کلاهبردارانه و تضمین سرویس قابل اعتماد برای مشتریانش استفاده می‌کند.
• پلتفرم‌های تجارت الکترونیک: بسیاری از پلتفرم‌های تجارت الکترونیک از محدودیت نرخ برای محافظت در برابر حملات ربات‌ها که سعی در استخراج اطلاعات محصول یا انجام حملات منع سرویس در طول فروش‌های فوق‌العاده دارند، استفاده می‌کنند.
• مؤسسات مالی: مؤسسات مالی محدودیت نرخ را بر روی APIهای خود پیاده‌سازی می‌کنند تا از دسترسی غیرمجاز به داده‌های مالی حساس جلوگیری کرده و از انطباق با الزامات نظارتی اطمینان حاصل کنند.

نتیجه‌گیری

محدودیت نرخ یک تکنیک ضروری برای محافظت از APIهای شما و تضمین پایداری و قابلیت اطمینان برنامه‌های شماست. الگوریتم‌های سطل نشانه و پنجره لغزان دو گزینه محبوب هستند که هر کدام نقاط قوت و ضعف خود را دارند. با درک این الگوریتم‌ها و پیروی از بهترین شیوه‌ها، می‌توانید به طور مؤثر محدودیت نرخ را در برنامه‌های پایتون خود پیاده‌سازی کرده و سیستم‌های مقاوم‌تر و ایمن‌تری بسازید. به یاد داشته باشید که نیازمندی‌های خاص خود را در نظر بگیرید، الگوریتم مناسب را با دقت انتخاب کنید و پیاده‌سازی خود را نظارت کنید تا اطمینان حاصل کنید که نیازهای شما را برآورده می‌کند. با مقیاس‌پذیر شدن برنامه شما، به کارگیری تکنیک‌های محدودیت نرخ توزیع‌شده را برای حفظ محدودیت نرخ سازگار در تمام سرورها در نظر بگیرید. اهمیت ارتباط واضح با مصرف‌کنندگان API از طریق هدرهای محدودیت نرخ و پیام‌های خطای آموزنده را فراموش نکنید.